Following conversation on CELLAR mailing list.

@michaelni

Block in many video and image codecs generally refers to a
rectgangular spatial area of pixels.
Macro block would refer to a larger square made of blocks.
We should not redefine commonly used terms. That could confuse people who
have worked with other video codecs

@dericed

I agree with Michael that the term Block may not be best. The NumBytes definition already uses FFV1 components. Could also consider packet, segment, or IMHO bitstream component was fine though long.

I agree on not redefining commonly used terms, but in that case component should not be used as it is sometimes used for defining the content of a Pixel ("Each of the three beams is called a component of that color").

I am in favor of packet, and the PR is modified accordingly.

Rebased

Why is bitstream unclear ?
You say it could be understood as the whole bitstream, but what is that ?
the container stores each frame and the configuration record seperately. I think it may be actually hard to define bitstream in a meaningfull way that combines these into one.
If bitstream feels unclear maybe "bitstream unit" would be an option?

You say it could be understood as the whole bitstream, but what is that ?

In some other specs, bitstream means the whole sequence of frames (concatenated). Raw bitstream broadcasting is not possible with FFV1, but people from the video world may have some difficulties to understand that this is about a frame (or configuration record) only.
There was at least one person (the reporter of the issue) who found current wording an issue.

I think it may be actually hard to define bitstream in a meaningfull way that combines these into one.

I think that the suggested change is better than current version, and could be improved in a future patch if someone else finds a better way.

If bitstream feels unclear maybe "bitstream unit" would be an option?

I prefer packet (because unit may have a different meaning e.g. measure unit) but I am not against unit. ping @dericed @ablwr who validated the PR with packet.

(To me, packet sounds related to data transmission.)

I think using "packet" can lead to confusion in an environment where there are network packets. These would very likely be 2 different things

I reviewed the Ogg specification at http://ietf.org/rfc/rfc3533.txt and think it may make sense to align with its use of bitstream and packet terminology.

Within RFC3533 it includes this paragraph in the definitions section:

The result of an Ogg encapsulation is called the "Physical (Ogg)
Bitstream". It encapsulates one or several encoder-created
bitstreams, which are called "Logical Bitstreams". A logical
bitstream, provided to the Ogg encapsulation process, has a
structure, i.e., it is split up into a sequence of so-called
"Packets". The packets are created by the encoder of that logical
bitstream and represent meaningful entities for that encoder only
(e.g., an uncompressed stream may use video frames as packets). They
do not contain boundary information - strung together they appear to
be streams of random bytes with no landmarks.

And adds a caveat that addresses @michaelni's consideration of confusion with the term.

Please note that the term "packet" is not used in this document to
signify entities for transport over a network.

I propose keeping the use of bitstream and packet in use similarly with Ogg and adding a similar paragraph and caveat as above to the PR.

I have a preference too for reusing same wording as in other RFC.

Reading again the OGG definitions part, difficult IMO to use it as is becaue it is the point of view of a container and not a coding format. I added the definition of Container and Packet, adapting the first part and keeping as is the part about avoid the confusion.

Please review

Reading again the OGG definitions part, difficult IMO to use it as is becaue it is the point of view of a container and not a coding format.

That’s my feeling too.

If you want to use terminology from an existing Specification then H264/H265/mpeg4/H222 access unit could be used.
For reference this is what H.222 says:
2.1.1 access unit (system): A coded representation of a presentation unit. In the case of audio, an access unit is the
coded representation of an audio frame, whereby each audio frame carries data from one or more audio channels; an
audio frame may carry for example one mono channel, or two stereo channels or seven surround sound channels.
In the case of video, an access unit includes all the coded data for a picture, and any stuffing that follows it, up to but
not including the start of the next access unit. If a picture is not preceded by a group_start_code or a
sequence_header_code, the access unit begins with the picture start code. If a picture is preceded by a group_start_code
and/or a sequence_header_code, the access unit begins with the first byte of the first of these start codes. If it is the last
picture preceding a sequence_end_code in the bitstream, all bytes between the last byte of the coded picture and the
sequence_end_code (including the sequence_end_code) belong to the access unit.
For the definition of an access unit for Rec. ITU-T H.264 | ISO/IEC 14496-10 video, see the AVC access unit definition
in 2.1.3.
In the case of an ISO/IEC 14496-17 text stream, see ISO/IEC 14496-17 for the definition of an access unit.

H264:
3.1 access unit: A set of NAL units that are consecutive in decoding order and contain exactly one primary coded
picture. In addition to the primary coded picture, an access unit may also contain one or more redundant coded
pictures, one auxiliary coded picture, or other NAL units not containing slices or slice data partitions of a coded
picture. The decoding of an access unit always results in a decoded picture.

I am ok with Access Unit though have a slight preference to packet. Unlike the h262/h264 definitions in the case of FFV1, the term Access Unit would have to be defined to include the Configuration Record as well rather than simply the frames as the remaining_bits_in_bitstream() function is used for both.

Why would it need to include the Configuration Record ? (That would be wrong for what an AU generally means)

I presumed that the suggestion would change remaining_bits_in_bitstream() to remaining_bits_in_access_unit(). This function is used within the definition of the Configuration Record at https://github.com/FFmpeg/FFV1/blob/master/ffv1.md#configuration-record

We could write "Access unit or Configuration Record" or something like that

To confirm, you mean keep the term remaining_bits_in_bitstream() but change definition to:

means the count of remaining bits after the pointer in that Access unit or Configuration Record.

? Seems fine.

Yes, this is a possibility

We could write "Access unit or Configuration Record" or something like that

Issue with that is that "Access Unit" becomes a synonym of "Frame", and we would have to change any instance of "Frame" word (huge).

IIUC decision is to keep "bitstream" wording, so I changed of method:

• I explicitly indicate "Configuration Record or Frame" (BTW it removes an issue about "component" word used for 2 different things in current spec) in remaining_bits_in_bitstream()
• I explicitly define Configuration Record and Frame as well as container, so it is more visible that only Configuration Record and Frame are linked to the container.

I think it would clarify the meaning of "bitstream" while keeping this word, removing the concern about the usage of this word.

Please review again.

I made the changes suggested in the discussion here and added backtick quoting to some defined terms. Please re-review.

Please re-review.

Fine for me (I can't approve my own PR :) )

Circular definitions:
+Container: Format that encapsulates Frames and (when required) a Configuration Record into a bitstream.
+
+Configuration Record: Encoder-created bitstream encapsulated in a container, representing a meaningful non-visual element used for setting up the decoder.

And it sounds confusing

In this case I suggest to remove the Configuration Record definition from the patch as it is well defined in its own section later in the document.

I removed Configuration Record (and Frame for the same reason), and rebased.
Now very light PR :).

bump on this, I think all concerns were handled, and the patch is small.